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FOREWORD 


This  docufent  describes  the  approved  transition  strategy  for  the 
Advanced  Autonation  System  (AAS)  and  provides  information  and  guidance 
to  individuals  and  organisations  involved  in  the  planning,  development 
and  implementation  of  the  AAS. 


Advanced  Autonation  Program  Office,  AAP-1 


lit 


PREFACE 


This  report  presents  FAA's  strategy  for  automation  system  transition  fron 
today's  en  route  and  terminal  facilities  to  an  Advanced  Autonation  Systen 
(AAS)  at  23  Area  Control  Facilities  (ACF)  and  sons  300  Air  Traffic 
Control  Toners  (AXCTs). 

Hie  report  is  organized  into  three  chapters: 

Chapter  1  serves  as  an  introduction.  It  defines  the  scope  of  the 
Advanced  Autonation  Progran  and  relates  it  to  the  National  Airspace 
Systen  Pin;  it  defines  AAS  transition  requirements  and  precepts;  and 
finally,  it  provides  an  overview  of  the  transition  steps  at  the  20 
continental  U.S.  (CCNUS)  Air  Route  Traffic  Control  Centers  (AKTGCs)  and 
of  the  operational  transition  fron  an  en  route/terninal  systen  to  a 
systen  of  23  AGFs,  each  with  a  colon  autonation  systen,  called  an  Area 
Control  Coaputer  Conplex  (ACCC),  and  approxiaately  300  Air  Traffic 
Control  Towers,  each  with  a  Tower  Control  Coaputer  Coaplex  (TCCC). 

Chapter  2  presents  a  detailed  discussion  of  each  of  the  four  transition 
steps.  Transition  will  begin  at  the  CONUS  ARTCCs  auch  earlier  than  for 
the  ACCC  at  the  three  other  ACFs  (Anchorage,  Honolulu,  and  New  York 
TRAGON),  or  for  the  TCCC  at  towers.  Correspondingly,  more  planning  has 
been  done  for  the  CONUS  ARTCCs  transition  and  therefore,  more  detail  is 
provided  for  the  three  steps  at  the  CONUS  ARTCCs  transition. 

Chapter  3  presents  a  short  staaary  of  the  transition. 

The  report  is  intended  to  convey  to  the  reader  FAA's  approach  to 
transition  and  the  rationale  for  the  selection  of  this  particular 
approach.  The  report  will  provide  the  foundation  for  the  development  of 
a  hierarchy  of  transition  dociaents.  These  consist  of  FAA  Implementation 
Plans  for  Host  Systen,  Initial  Sector  Suite  Systen,  and  Advanced 
Autonation  Systen.  Lower  level,  design  dependent  transition  planning 
documents  are  expected  to  be  developed  by  the  .Host  and  AAS  prime 
contractors. 

This  report  also  addresses  broad  training  requirements  associated  with 
the  different  transition  steps.  A  more  detailed  plan  for  trainiig  will 
be  provided  by  FAA  in  the  Advanced  Autonation  Progran  Integrated 
Logistics  Support  (ILS)  Plan. 

Finally,  the  Advanced  Autonation  Progran  Office  technical,  aanagenent, 
and  acquisition  approaches  will  be  delineated  in  a  Progran  Master  Plan, 
Progran  Management  Plan,  and  a  Technical  Development  Plan. 
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TRANSITION  TO  THE  ADVANCED  AUTONATION  SYSTBf 


1.0  IWraODUCTION 

1.1  Objectives 

The  National  Airspace  Systea  (NAS)  Plan  (Deceaber  1981)  has  outlined  an 
ambitious  approach  to  the  Modernization  of  the  National  Airspace  Systea. 
The  development  and  iapleaentation  of  the  Advanced  Autoaation  Systea 
(AAS)  to  support  en  route  and  terminal  air  traffic  control  is  an  integral 
part  of  the  NAS  Plan.  This  report  lays  out  an  approach,  with  rationale, 
to  the  transition  froa  today's  en  route  and  terminal  autoaation  systeas 
to  an  Area  Control  Coaputer  Complex  (ACCC)  at  23  Area  Control  Facilities 
(ACFs).  The  approach  presented  here  has  been  approved  and  fora s  the 
basis  for  auch  of  the  Advanced  Autoaation  Prograa  planning.  It  is 
reflected  in  the  procurement  packages  for  Host  and  AAS  systeas,  in  the 
detailed  transition,  facility  Modernization,  test,  trainiig,  and  budget 
planning  by  the  Advanced  Autoaation  Prograa  Office  (AAPO),  and  in  the 
definition  of  relationships  with  other  programs  and  interfaces  with  other 
systeas  that  fora  part  of  the  NAS  Plan. 

1.2  Background 

The  present  air  traffic  control  systea  is  comprised  of  FAA  ground 
facilities  that  provide  en  route  and  terminal  air  traffic  control 
services.  Aircraft  flying  en  route  between  terminal  areas  and  operating 
under  instrument  flight  rules  are  controlled  by  air  route  traffic  control 
centers  (ARTGCs).  There  are  20  ARTGCs  in  the  Continental  United  States 
(CONUS)  and  three  offshore  centers.  In  terminal  areas,  there  are  about 
400  airport  traffic  control  towers  (ATCTs)  each  of  which  is  located  on 
the  surface  of  the  airport  it  serves.  Almost  200  of  these  ATCTs  are 
served  by  terminal  radar  approach  control  (TRAOQN/TRACAB)  facilities  that 
provide  air  traffic  control  services  to  aircraft  arriving  at  and 
departing  from  the  airport  being  served.  Normally  each  TRAG0N  is 
associated  with  one  ATCT  and  located  within  the  sane  building.  However, 
a  TRACCN  nay  be  remotely  located  and  serve  more  than  one  ATCT.  A  TRACAB 
is  located  within  the  ATCT  cab  at  an  airport  with  a  low-traffic  density. 

The  National  Airspace  Systea  Plan  calls  for  an  evolution  in  en  route  and 
terminal  air  traffic  control  systems  froa  the  present  until  the  year  2000 
and  beyond  in  two  related  areas  —  new  and  improved  automation  sigjport 
and  consolidation  of  existing  facilities.  The  AAS  shall  directly  support 
both  of  these  related  efforts  by: 

1.  Providing  an  integrated  computing  systea  as  a  basis  for  consolidation 
of  operations, 

2.  Replacing  existing,  aging  autoaation  equipment, 

3.  Adding  new  autoaation  capabilities,  and 

4.  Allowing  the  use  of  coion  equipment  to  perform  similar  functions. 
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During  this  evolution  the  existing  ARTCCs  and  TRACON/TRACAB  facilities 
will  be  consolidated  to  for*  Area  Control  Facilities  (ACP).  All  en  route 
and  approach/departure  control  will  be  accomplished  from  23  ACFs.  The 
Area  Control  Computer  Complex  (ACCC)  at  the  ACFs  win  be  tied,  via  a 
telecommunication  network,  to  Tower  Control  Computer  Complexes  (TGCCs)  at 
some  300  Air  Traffic  Control  Towers  (ATCT).  It  is  planned  that  the  20 
Conus  ARTCCs.  the  NY  1RAC0N,  Anchorage  ARTCC,  and  Honolulu  ARTCC  will 
make  up  the  23  ACFs. 


The  Advanced  Automation  Program  (AAP)  will  provide  all  the  automation 
equipment  and  software  required  for  air  traffic  control  at  the  ACFs  and 
at  tile  ATCTs  and  the  support  equipment  required,  primarily  at  the  FAA 
Technical  Center  (FAATC),  to  test  and  maintain  the  software  and  hardware 
for  the  systems  at  the  operational  sites.  Site  preparation/construction, 
training,  logistics,  and  field  support  will  also  be  part  of  the  AAP. 


The  Advanced  Automation  Program  includes  responsibility  for  the 
transition  from  today's  automation  and  support  systems  to  the  Advanced 
Automation  Systems  and  for  any  development  and  implementation  activity 
required  by  this  transition. 


The  Advanced  Automation  System  will  provide  an  overall  design  that  can 
accommodate  the  ATC  evolution  of  the  1990-2010  era.  When  initially 
installed,  the  system  will  have  the  capability  to  perform  today's 
functions,  a  number  of  near  term  enhancements  (conflict  alert  for  VFR 
intruders,  conflict  resolution  advisories  and  improved  en  route 
metering),  and  AERA  I  -  the  initial  elements  (direct  route  planning  and 
improved  flow  management)  of  the  Automated  En  Route  ATC  (AERA)  system. 

The  AAS  will  be  capable  of  supporting  en  route  and  terminal  ATC  in  a 
single  system.  It  will  have  a  greatly  improved  man/machine  interface, 
including  a  totally  new  controller  work  station  (sector  suite)  for 
greater  productivity.  The  AAS  is  characterized  by  increased  availability 
and  reliability,  lower  cost  maintenance,  and  flexibility  for  technology 
upgrading.  Its  evolutionary  design  will  accommodate  traffic  growth, 
changes  in  the  ATC  environment,  new  functions  (e.g.,  AERA),  and  new  data 
sources  (surveillance  systems,  navigation  systems,  communication  systems) 
described  in  the  NAS  Plan. 


The  AAS,  when  fully  installed  in  the  early  to  mid  1990's,  will  contain 
five  major  elements:  an  Area  Control  Computer  Complex  (ACCC)  at  each 
ACF;  a  Tower  Control  Computer  Complex  (TCCC)  at  each  of  300  ATCT;  a 
System  Support  Computer  Complex  (SSCC)  at  the  FAATC;  a  Research  and 
Development  Computer  Complex  (RDCC)  at  the  FAATC;  and  an  Advanced 
Automation  Training  System  with  elements  at  each  of  the  above  facilities 
and  at  the  FAA  Academy. 


The  ACCC  will  consist  of  a  newly  designed  distributed  computer  hardware 
and  software  system;  a  Local  Communication  Network  (LQQ  to  handle  the 
non-voice  communication  within  the  ACCC,  between  the  ACCC  and  other 
systems  at  an  ACF  (Flight  Service  Data  Processing  System,  Center  Weather 
Processor,  and  Maintenance  Processing  System),  and  the  intrafacility 
cr—mi cation  between  these  other  ACF  systems;  and  a  newly  designed 
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sector  suite  that  incorporates  new  input  and  output  devices,  including  a 
display  for  electronic  presentation  of  flight  data  intonation  (to 
replace  the  existing  printed  flight  strips;.  The  TOQC  will  contain:  new 
TCCC  position  consoles;  any  local  computer  hardware  and  software  required 
by  the  AAS  design;  and  interfaces  to  airport  sensor  systems,  including 
the  applicable  terminal  surveillance  systems).  System  Support  at  the 
FAATC  will  be  provided  by  a  System  Sipport  Computer  Complex  (SSGC)  which 
contains  the  hardware  and  software  for:  replicating  any  ACGC  and  TOCC; 
replicating  two  ACCCs  simultaneously;  reconfiguration  of  the  equipment 
into  the  above  systems;  and  hardware  and  software  to  support  all  system 
maintenance  activities.  Finally,  there  will  be,  at  the  FAATC,  a  Research 
and  Development  Computer  Coaplex  (RDCC)  that  contains  all  elements  of  an 
ACOC  (including  six  sector  suites)  and  a  TCCC. 

1.4  Transition  Requirements 

Three  characteristics  of  the  ATC  Automation  System  drive  the  transition 
strategy.  First,  and  most  important,  Air  Traffic  Control  is  a  24  hour  a 
day,  seven  days  a  week  operation  that  cannot  be  interrupted  as  new 
automation  hardware  and  software  are  introduced. 

Second,  the  introduction  of  new  system  elements  cannot  in  any  way 
jeopardize  the  safety  of  air  traffic  operations.  This  means  that 
installation  should  not  disrupt  ongoing  ATC  operations.  During  the 
initial  period  of  operation,  care  must  be  taken  that  equipment  failures 
are  minimized  and  that  adequate  backup  equipment  is  available  should 
failures  occur.  It  also  means  that  new  methods  of  operation  and  new 
controller  input/output  techniques  must  be  introduced  in  a  manner  that 
minimizes  the  potential  for  hwan  error.  Adequate  training  and  limiting 
the  ntmiber  of  different  man/machine  configurations  during  the  transition 
will  help  in  this  respect. 

The  third  characteristic  of  the  ATC  automation  system  that  has  important 
transition  considerations  is  its  size  (on  the  order  of  one  million  lines 
of  code)  and  the  fact  that  it  is  a  single,  integrated  system.  Experience 
with  other  large  systems  has  shown  that  the  transition  must  be  approached 
in  several  manageable  steps  rather  than  In  one  single  step.  Generally 
this  is  achieved  by  upgrading  or  replacing  a  system  a  few  functions  at  a 
tine.  Unfortunately,  the  existing  ATC  software  is  not  capable  of  being 
functionally  partitioned  and  therefore,  does  not  lend  itself  to  such  a 
transition  strategy. 

1.5  Transition  Precepts 

The  selection  of  the  transition  strategy  that  has  been  adopted  for  the 
AAS  by  FAA  has  been  guided  by  a  number  of  precepts.  These  are: 

1.  Capacity  improvements  to  the  en  route  ATC  autoaution  system  will  be 
needed  in  the  1986/87  timeframe.  Analysis  has  shorn  that  en  route 
software  cannot  be  replaced  in  time  to  meet  this  need. 


2.  The  transition  approach  should  provide  increases  in  controller 
productivity  at  the  earliest  possible  time. 


3.  An  AAS  design  for  a  system  architecture  that  has  a  20-30  year  life  is 
a  primary  objective  of  the  Advanced  Automation  Program.  This 
objective  should  not  be  jeopardized  by  the  transition  approach. 

4.  AAS  transition  shall  not  be  dependent  on  the  ampletion  of  any  other 
elements  of  the  NAS  Plan  except  for  the  new  Voice  Switching  and 
Control  System  (VSCS).  VSCS  must  be  installed  with  (or  prior  to) 
implementation  of  new  sector  suites. 

5.  To  minimize  operational  disruption,  the  transition  approach  shall 
minimize  the  total  duration  of  the  equipment  installation  and 
checkout  period  for  any  transition  step  at  a  single  facility. 

6.  There  shall  be,  at  a  minimum,  a  two  year  stabilization  period  between 
the  transition  steps. 

7.  The  basic  transition  strategy  for  each  transition  step  is  to  switch 
all  operations  from  the  old  to  the  new  system  at  the  same  time  in  any 
one  facility.  Thus,  for  example,  when  new  sector  suites  are 
installed  in  an  ARTCC,  Air  Traffic  Control  operation  at  that  center 
will  be  done  either  using  all  new  sector  suites  or  all  old  PVD/flight 
strip  printer  equipment.  There  will  never  be  an  operational  system 
in  a  single  facility  that  uses  some  old  and  some  new  sector  suites. 

8.  To  permit  full  operational  checkout  and  carefully  stage  operational 
introduction  of  the  system  installed  at  each  transition  step,  it 
shall  be  possible,  for  a  limited  period,  to  fully  operate  the 
facility  with  either  the  new  system  or  with  the  system  that  was 
operational  prior  to  this  transition  step. 

9.  It  shall  be  possible  to  simultaneously  perform  full  ATC  operations 
with  the  old  system  and  perform  initial  checkout  and  controller 
training  with  the  "new"  system  at  each  step  of  the  transition. 

10.  While  transition  to  the  ultimate  system  described  in  the  NAS  Plan 
will  be  carried  out  in  multiple  steps  over  an  extended  period,  all 
construction/site  preparation  necessary  at  any  given  facility  shall 
be  carried  out  in  a  single  building  program,  where  practical. 

1.6  Backup  Philosophy 

At  every  step  of  the  transition  a  new  system  configuration  is  made 
operational  which  will  have  all  the  requisite  redundancy  and  backiq>  modes 
built  into  it.  Because  of  the  serious  concern  with  providing  automation 
support  to  controllers  at  all  times,  these  "normal"  back-up  mechanisms 
will  not  be  adequate  during  the  initial  period  when  a  new  system 
configuration  is  first  put  into  operation.  During  this  initial  period 
additional  backup  mechanisms,  consistent  with  the  general  transition 
backup  philosophy  outlined  below,  will  be  made  available.  These 
additional  backup  mechanisms  will  remain  in  place  until  the  new  system  is 
perceived  to  be  sufficiently  stable  by  the  users  (i.e.  the  Air  Traffic 
Service) . 

The  general  transition  backup  philosophy  requires,  at  each  step  in  the 
transition,  the  availability  of  DARC  and  the  availability  of  the  old 
system  configuration.  For  example,  when  a  new  computer  (Host)  is 
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installed  to  replace  the  9020  Computer  it  Mist  be  possible  to  configure 
an  operational  systea  based  on  the  Host  and,  at  other  tines,  to  configure 
a  systea  based  on  the  9020  Coaputer.  The  following  backup  process  will 
be  followed: 


If  the  new  systea  fails,  controllers  will  continue  operations  with 
DARC.  Atteapts  will  be  Bade  to  restart  the  new  systea. 

If  the  new  systea  cannot  be  restarted  within  an  operationally 
acceptable  tine  period,  the  old  systea  will  be  started  up  froa  a 
dormant  state.  During  startup,  the  old  systea  will  generate  the 
active  (flight  and  surveillance)  data  bases  because  data  generated  by 
the  failed  new  systea  cannot  be  trusted. 

Operation  will  continue  with  the  old  systea  until  the  new  systea  is 
once  again  judged  to  be  operationally  satisfactory. 

Locally  developed  operational  procedures  will  address  conversion  to 
manual  flight  data  processing. 

DARC  will  remain  in  place  after  the  old  systea  is  reaoved  at  each 
transition  step  except  the  last.  Because  DARC  plays  such  an  important 
rolu  in  providing  ATC  service  continuity  during  the  transition,  the 
functional  capabilities,  including  the  sector  by  sector  switchover 
provided  oy  Enhanced  DARC,  are  required. 

1.7  Transition  Steps  -  Overview 

The  transition  strategy  selected  for  the  AAS  is  built  around  a  step-wise 
transition  of  the  en  route  automation  system  at  the  20  Continental  U.S. 
(CONUS)  ARTCCs. 

This  entails  three  discrete  steps  (Figure  1).  First,  the  9020A  and  D 
central  computer  hardware  will  be  replaced  by  a  new,  instruction 
compatible.  Host  computer.  In  this  configuration,  called  the  Host 
System,  existing  software  will  be  retained.  Next,  a  new  controller  work 
station  (sector  suite)  will  be  introduced.  This  automation  system 
configuration,  called  the  Initial  Sector  Suite  System  (ISSS),  will 
provide  a  new  radar  situation  display  as  well  as  electronic  tabular 
display  and  electronic  manipulation  of  flight  progress  information.  The 
major  portion  of  the  ATC  data  processing  of  the  ISSS  will  be  done  by  9020 
software  in  the  Host  computer.  Some  new  computer  hardware  and  software 
as  well  as  a  subset  of  the  ACCC  Local  Conaunication  Network  (LCN)  will  be 
required  for  the  ISSS. 

In  the  third  step,  the  full  ACCC  will  be  implemented  at  the  en  route 
centers  by  augmenting  the  ISSS  coaputer  hardware,  installation  of  the  ■ 
remainder  of  the  LCN,  and  installation  of  the  complete  ACCC  software. 
During  this  period  ACCC  equipment  will  also  be  introduced  at  the 
remaining  three  ACFs  (Anchorage,  Honolulu,  and  the  New  York  Tracon). 

After  the  ACCC  at  the  20  CONUS  en  route  centers  (by  then  called  ACFs) 
becomes  stable,  the  gradual  operational  consolidation  of  terminal  radar 
sectors  into  the  ACCC  can  begin.  When  the  approach  and  departure  control 
for  an  airport  is  transferred  to  an  ACCC,  a  Tower  Control  Coaputer 
Complex  (TCCC)  will  be  installed  and  become  operational  at  that 
airport. 


This  approach  to  transition  decomposes  the  implementation  of  a  large  new 
system,  the  AAS,  into  four  manageable  steps  and  thereby  offers  a 
significant  reduction  in  Advanced  Automation  Program  technical,  cost,  and 
schedule  risk.  The  particular  steps  selected  for  the  transition  also 
fulfill  a  number  of  other  important  requirements: 

1.  The  Host  System  will  provide  the  capacity  relief  required  at  some  of 
the  en  route  centers  in  the  aid  to  late  1980's  and  the  ability  to 
support  some  near  tern  functional  improvements. 

2.  The  1SSS  will,  through  an  improved  man/ machine  interface, 
particularly  the  automation  of  flight  data  presentation,  entry,  and 
manipulation,  reduce  controller  staffing  needs  (productivity 
improvement).  While  the  full  ACCC  will  also  satisfy  the  capacity 
demands  and  productivity  requirements  of  the  ATC  system,  it  could  not 
provide  the  Benefits  as  early  as  the  Host  System  or  even  ISSS  as  its 
development  schedule  is  constrained  by  the  time  required  to  design, 
develop,  and  fully  test  new  ATC  software. 

3.  The  ACCC  will  provide  automation  functions  for  more  fuel  efficient 
flight  (AERA  I)  and  will  serve  as  the  building  block  for  the  ATC 
evolution  of  the  1990-2010  era. 

4.  Finally,  the  incorporation  of  terminal  control  into  a  single  Advanced 
Control  Computer  Complex  and  the  accompanying  introduction  of  TCCCs 
brings  with  it  new  operational  efficiency  in  terminal  hubs,  the 
potential  for  increases  in  terminal  automation,  and  the  operational 
and  maintenance  benefits  of  facility  consolidation. 


2.0  TRANSITION 


2.1  Introduction 

This  chapter  will  provide  a  detailed  description  of  the  three  transition 
steps  at  the  20  en  route  facilities  and  of  the  operational  transition  to 
23  fully  consolidated  ACFs  and  sone  300  ATCTs.  The  discussions  will 
focus  on:  a  description  of  the  systea  implemented;  the  fall-back 
aechanisa  eaployed  when  a  systea  is  first  installed;  facility 
requireaents  and  impact;  staffing  impact;  unique  operational 
characteristics  of  the  systea  configuration;  training  requireaents; 
support  facility  requireaents;  and  overall  iapact  on  the  Advanced 
Autoaation  Program. 

2.1.1  Generalized  Transition  Configurations 

While  the  configuration  of  the  systea  at  each  transition  step  can  be 
described  in  a  general  way,  only  the  configuration  for  the  Host  Systea  is 
known  in  a  detailed  way  at  this  tiae.  The  FAA  has  specified  a  general 
computer  systea  configuration  for  the  Host  Systea.  In  addition,  the  FAA 
has  identified  precisely  what  9020  equipaent  is  to  be  replaced  and  how 
the  Host  is  to  be  embedded  in  the  en  route  systea.  These  specifications 
were  based  on  extensive  FAA  Host  feasibility  and  risk  analysis.  In  the 
case  of  the  AAS,  FAA  has  chosen  to  specify  only  functional  and 
performance  requirements  and  to  give  the  responsibility  for  AAS  systea 
design  to  the  AAS  prime  contractors.  A  distributed  systea  architecture, 
built  around  a  local  connunications  network,  will  inherently  provide  high 
availability  and  protection  froa  total  systea  failure.  Details  of  the 
configuration  to  be  installed,  the  extent  of  equipaent  to  be  replaced, 
and  the  means  of  interfacing  to  existing  equipaent  at  the  second  and 
third  step  in  the  transition  will  be  the  responsibility  of  the  priae 
contractors. 

2.1.2  Representative  Transition  Diagrams 

A  series  of  "wiring"  diagrams  will  be  used  in  the  following  sections  for 
ease  of  exposition  of  the  technical  aspects  of  transition.  Because  it  is 
impossible  to  draw  such  diagrams  in  an  absolutely  generic  and  design 
independent  Banner,  the  diagrams  that  are  used  in  the  ISSS  and  AGGC 
sections  show  specific  connectivities.  For  example,  ISSS,  in  these 
diagrams,  does  not  replace  the  display  channel  but,  in  point  of  fact,  the 
decision  to  replace  or  not  replace  the  display  channel  will  be  based  on 
priae  contractor  designs  and  recommendations.  Thus  these  diagrams, 
except  for  Host  transition,  should  not  be  considered  literally,  either  as 
a  requirement  or  a  preferred  FAA  approach.  The  text  in  these  sections 
will  clearly  identify  what  the  FAA  requireaents  are  and  where  the 
contractor  has  design  and  interface  definition  freedom.  For  each  step 
two  illustrative  diagrams  will  be  used,  one  to  show  the  initial 
configuration  with  a  fallback  systea  and  one  to  show  the  systea  after 
reaoval  of  the  fallback  systea. 


2.1.3  Transition  States 

To  simplify  the  discussion,  four  states  of  the  systea  ere  defined  es 
follows: 


State  0  -  Today's  Systea 
State  1  -  Host  Systea 
State  2  -  ISSS 
State  3  -  ACC C 

The  initial  configuration  at  each  transition  step,  when  a  fallback  systea 
is  still  in  place,  will  be  denoted  as  Step  0/1,  Step  1/2,  etc.  The 
starting  point  for  the  transition  discussion  is  today's  systea.  State  0 
(See  Figure  2).  The  systea  consists  of  the  9020  Central  Computer  Coaplex 
(denoted  as  9020A  or  9020D)  which  is  a  Multiprocessor  aade  up  of 
specially  Modified  IBM  360  computers;  associated  standard  peripherals;  a 
Peripheral  Adapter  Module  (PAM)  that  serves  as  the  coanuni  cat  ions  gateway 
for  other  facilities,  surveillance  inputs,  and  flight  strip  printers  in 
the  control  roan;  a  Display  Channel  that  sets  up  the  displays  for 
individual  Plan  View  Displays  (PVDs)  and  contains  both  the  refresh  nenory 
for  all  displays  and  the  Radar  Keyboard  Multiplexor  (RKM);  a  set  of 
Display  Generators  (DG),  each  of  which  drives  six  PVDs;  and  the  Direct 
Access  Radar  Channel  (DARC)  which  provides  a  backup  radar  presentation 
and  ties  directly  into  the  display  generators. 

2.2  Host  Transition 


The  Host  transition  is  the  first  step  (Step  0/1)  in  a  series  of  three 
transition  steps  that  will  transform  today's  ATC  computer  systea  into  the 
ACCCs.  The  purpose  of  this  transition  is  to  replace  the  9020  computer 
systeas  with  IBM  360/370  instruction  coapatible  computer  systems  and  to 

Provide  additional  processing  capacity  consistent  with  the  growing  demand 
or  ATC  services. 

2.2.1  System  Definition 

The  Host  computer  system  is  a  current  generation  IBM  360/370  instruction 
coapatible  replacement  for  the  9020  Computer.  Where  the  9020  Computer 
required  several  processors  to  handle  the  en  route  ATC  load,  today's 
technology  permits  a  single,  medium- si zed  computer  to  handle  the  entire 
load.  High  availability  in  the  9020  Computer  was  provided  by  redundant 
elements  in  the  multiprocessor  configuration;  in  the  Host  this  will  be 
provided  by  a  second  standby  computer  connected  through  new  standard 
peripherals.  The  Host  will  execute  9020  software  adapted  to  operate  on  a 
current  generation  off-the-shelf  computer.  The  Host  will  be  tied  into 
the  existing  system  through  the  PAM  (standard  IBM  360/370  multiplexor 
channel  interface)  and  the  display  channel  (standard  IBM  360/370  selector 
channel  interface).  Off-the-shelf  charnel  switches  will  be  provided  to 
penit  systea  operation  with  either  the  Host  or  with  the  9020  Central 
Computer  Complex.  These  and  the  9020  GGC  will  be  removed  after  the  Host 
has  demonstrated  a  satisfactory  level  of  stability  during  operational 
use.  Figures  3  and  4  show  the  Host  configuration  with  the  9020  (kmgxiter 
in  place  and  after  9020  Computer  removal. 
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2.2.2  Bactag?  Mechanise 

During  the  Host  stabilization  period,  Host  failure  will  lead  to  ATC 
operations  with  DARC  If  (refer  to  Figure  3  for  this  discussion).  The 
Host  recovery  nechanisn  (i.e. ,  autonatic  switchover  to  the  badog)  Host 
computer)  is  attenpted,  and,  if  susccessful,  ATC  operations  can  continue 
with  Host.  If  this  and  other,  naaual  attanpts  to  revive  the  Host  fail, 
facility  personnel  will  witch  the  Host  out  of  the  active  configuration 
and  sake  the  9020  CCC  the  active  systew.  This  will  require  a  relatively 
lengthy  start  ig>  since  the  9020  CCC  is  in  a  dornant  state  and  receives  no 
flight  and  radar  data  inputs  while  Host  is  active.  No  data  generated  by 
Host  will  be  used  by  the  9020  CCC  during  startup.  Because  the  fallback 
nechanisn  is  only  required  for  a  short  stabilisation  period  (estinated  at 
three  nonths  for  the  first  site  and  considerably  less  for  the  other 
sites)  and  because  problen  el  ini  nation  through  extensive  Host  testing  is 
expected  to  nake  switchover  to  the  9020  CCC  a  rare  event,  a  wore  rapid, 
warn  start  of  the  9020  CCC  is  not  required. 

2.2.3  Facility  Considerations 

A  conputer  roan  with  proper  environaental  conditions  will  be  required  at 
each  ARTCC  for  the  Host  conputer.  The  location  of  the  Host  has  been 
selected  on  the  basis  of  an  overall  plan  for  ARTCC  space  utilization 
during  the  transition  and  the  final  operational  inpleanntatiou  of  an 
ACF.  A  wiring  extension  will  be  constructed  to  expand  the  current 
control  roan  (first  and  second  floor)  and  to  house  (in  the  basenent)  the 
conputer  systeus  that  trill  ultimately  be  in  an  ACF  (see  Figure  5). 

Installation  of  Host  conputers  at  ARTCCs  will  begin  after  (a)  the 
extended  wing  construction  and  computer  roon  site  preparation  are 
finished  and  (b)  extensive  FAA  Host  tests  are  completed  at  FAATC.  These 
tests  trill  include  denonstration  of  Host  installation  and  9020  Systen  to 
Host  switchover  as  it  will  be  done  at  a  field  site.  Host  installation  at 
field  sites  will  begin  in  early  1986.  Operational  readiness 
denonstration  (0RD)  at  the  last  site  is  currently  planned  in  nid  1987 
(see  the  schedule,  Figure  6).  Several  installation  and  checkout  ton 
will  be  required  to  achieve  this  Host  inplenentatian  schedule.  The  Host 
prine  contractor  will  be  responsible  for  installation  checkout,  and 
testing  of  the  equipment.  FAA  will  accept  the  system  upon  contractor 
demonstration  of  full  system  operation  with  the  contractor  modified  9020 
software. 

Three  Host  systems  will  be  delivered  by  the  Host  prine  contractor  in 
addition  to  the  20  systens  for  CONUS  ARTCCs  .i/  One  of  these,  the 


Note  that  •  controller  has  the  ability  to  witch  his/her  radar 
presentation  (fron  Host  or  9020)  to  DARC  at  his  own  discretion. 


1/  An  optional,  24th,  systen  nay  be  procured  for  training  uae  at  the 
FAA  Acadeny.  If  procured,  this  systsn  will  be  oas  of  the  first 
to  be  delivered. 
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first  system  to  be  delivered,  goes  to  FAATC  for  production  phase 
testily.  Ibis  systea  will  becoae  the  Host  Systea  Support  Facility  at 
FAATC  after  testily  is  copleted.  The  other  two  systeaa  will  be 
provided,  as  Goveraaat  Furnished  Property,  to  the  two  AAS  contractors  in 
early  1985. 

2.2.4  Qperatiooal/Training  Iaoact 

The  operational  impact  of  Host  transition  on  the  air  traffic  controller 
will  be  ainiaal.  The  control  position  equipment  (PVD,  flight  strip 
printer  etc.)  is  not  affected  and  the  application  software  aodifications 
that  were  made  should  be  transparent  to  the  controller.  Sane  controller 
instruction  will,  be  required  to  faailiarize  the  controller  with  the 
failure  Mechanise  for  the  initial  Host  stabilisation  period. 

The  introduction  of  new  equipnent,  new  support  software,  a  new  control 
prog ran,  and  some  application  software  changes  will  have  an  iapact  on 
operations  and  aaintenence  personnel.  Training  of  computer  operators, 
hardware  aaintenance  technicians,  and  software  specialists  will  be 
required. 

2.2.5  Program  Considerations 

Three  important  program  considerations  drive  the  Host  prograa.  First, 
because  the  Host  Systea  trill  alleviate  the  serious  en  route  capacity 
concerns  for  the  aid-to-late  1980* s,  the  Host  prograa  has  been  structured 
to  Minimize  technical  and  schedule  risk.  This  consideration  is 
Manifested  in  the  particular  selection  of  the  Host  interfaces  to  the 
existing  en  route  systea  and  in  the  determination  of  the  acquisiton 
approach.  It  also  gave  rise  to  the  requirement  for  minimizing  changes  to 
the  coaplex  9020  software  during  the  rehosting  process. 

The  second  consideration  is  the  necessity  for  ATC  system  stability  during 
subsequent  transition  steps.  Once  installed  at  an  ARTCC,  the  Host 
computer  should  remain  in  place  at  least  until  the  ACCC  has  becoae  stable 
at  that  facility.  This  implies  that  a  Host  should  not  be  relocated 
within  the  facility  and  that  the  Host  should  not  be  replaced  or  upgraded 
to  a  different  model  computer.  For  this  reason,  the  Host  will  have 
sufficient  capacity  to  execute  9020  software  under  a  virtual  —rhin* 
operating  systea  for  a  1995  scenario  at  the  largest  en  route  center. 


Third,  the  desire  for  an  unconstrained  total  AAS  design  that  can  meet 
long  tern  ATC  needs  in  a  cost  effective  Banner  has  had  an  iapact  on  the 
overall  transition  strategy.  In  particular,  the  Host  computer 
specification  was  in  no  way  based  on  AAS  functional  and  performance 
retirements.  Ibis,  together  with  the  AAS  design  evaluation  criteria, 
will  ensure  that  the  existence  of  Host  will  not  bias  the  AAS  design  and 
that  the  consideration  of  Host  for  use  in  the  ultimate  ACCC  will  be  based 
strictly  on  life  cycle  cost  considerations.  While  the  9020  software  will 
have  to  be  Modified  to  operate  with  the  ISSS  flight  data  presentation  and 
manipulation  systea,  FAA  experience  with  an  early  experimental  version  of 
such  a  systea  (Electronic  Tabular  Display  Systea  -  ETABS)  demonstrated 
the  feasibility  of  the  necessary  aodifications.  FAA  analysis  predicts 
that  capacity  iapact  of  software  modifications  on  Host  would  be 
negligible.  Finally,  to  facilitate  the  introduction  of  ISSS  and  AAS 
transition  and  the  fallback  mechanisms  for  those  systems,  a  virtual 
machine  control  prograa  was  specified  for  Host. 


2.3  ISSS  Transition 


The  Initial  Sector  Suite  Systen  (ISSS)  transition  is  the  second  step 
(Step  1/2)  in  the  deployment  of  the  AGGC.  The  ISSS  introduces  the  new 
MS  nan/aachine  interface  to  the  ARTOC  and  enables  productivity 
improvements  in  the  support  for  ATC  services. 

2.3.1  Systen  Definition 

The  ISSS  introduces  the  new  sector  suite  with  its  display  and  input 
devices  and  new  nethods  for  the  controller  and  automation  system  to 
communicate  (i.e.,  a  new  nan/nachine  "language") .  Physically,  the  sector 
suite  will  meet  the  ultimate  AAS  requirements  and  therefore,  will  not 
require  modification  in  later  transition  steps,  with  the  possible 
exception  of  changes  to  some  interim  interfaces  that  are  required  to 
operate  with  the  ARTCC  equipment  in  the  Host  systen  configuration.  The 
sector  suite  will  consist  of  one  to  four  identical  (common)  consoles  each 
of  which  will  have  a  VS CS  panel.  Each  console  will  contain  one  or  more 
embedded  microprocessors  for  display  refresh  and  handling  device 
input/output.  At  least  one  of  the  consoles  of  a  sector  suite  will  have 
an  interface  to  DARC,  designed  so  that  this  console  will  be  able  to 
provide  the  controller  with  a  radar  presentation  if  the  radar  data 
processing  portion  of  the  ISSS  fails.  This  interface  will  be  required 
through  the  next  transition  step,  until  the  ACCC  becomes  stable. 


2. 3. 1.1  Systen  Configuration 

The  ISSS  will  consist  of  an  AAS  design-dependent  combination  of  Host 
systen  elements,  ACCC  systen  elements ,  and  the  interim  software  and 
hardware  required  to  tie  the  Host  and  ACCC  elements  together  into  an 
operational  system.  In  addition  to  the  sector  suite,  it  will  contain  a 
small  subset  of  the  ACCC  computer  hardware  and  software,  the  Host 
computer  and  9020  software,  and  the  subset  of  the  ACCC  Local 
Communications  Network  (LCN)  necessary  to  support  communications  among 
these  elements.  Finally,  a  (design  dependent)  mechanism  to  provide  the 
switching  between  ISSS  and  Host  System  (with  PVDs  and  flight  strip 
printers)  is  required.  This  mechanism  will  be  removed  together  with  the 
old  control  roam  equipment  (PVDs,  flight  strip  printers,  etc.)  and  any 
other  equipment  (e.g. ,  portions  of  the  display  channel)  the  AAS  prime 
contractor  chooses  to  replace  with  new  ISSS  equipment. 


At  this  transition  step  the  bulk  of  the  ATC  data  processing  is  still 
being  performed  by  the  9020  software  in  the  Host  system.  New  (ACCC) 
software  will  be  required  for  the  new  nan/nachine  interface  (language), 
particularly  flight  data  display  and  manipulation.  Modifications  to  tne 
9020  software  will  be  needed  to  provide  the  appropriate  data  base 
interface  to  the  new  flight  data  display  and  manipulation  software. 


2. 3.1. 2  Representative  ISSS  Architecture 

Figures  6  and  7  present  one  of  many  possible  ISSS  architectures.  They 
illustrate  that  the  AAS  prime  contractor  has  the  freedom  to  distribute 
some  processing  to  an  application  computer  systems  dedicated  to  each 
sector  suite,  to  possible  new  "central"  processor(s),  or,  for  that 
natter,  to  the  Host.  The  "distributed  sector  suite  processing  block" 
over  two  of  the  cannon  consoles  but  not  over  the  radar  (W)  console 
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illustrates:  (a)  the  requirement  for  a  relatively  independent  naans  to 
preserve  flight  data  infoimation  when  the  ISSS  fails  -  a  replacement  for 
the  current  annual  capability  to  nark  and  sort  (paper)  flight  progress 
strips  and  to  pass  then  to  controllers  of  adjacent  sectors  (no  flight 
strips  will  be  printed  by  the  ISSS);  and  (b)  the  absence  of  a  requirement 
to  provide  backup  radar  processing  (since  DARC  still  serves  that 
function).  An  ISSS  design  that  includes  backtq>  radar  processing  will  be 
permitted  so  long  as  this  feature  does  not  adversely  impact  the  ISSS 
development  schedule.  The  "interim  interfaces"  are  included  in  the 
Figures  in  recognition  of  the  potential  need  in  the  ISSS  for  both 
hardware  and  software  that  will  not  be  part  of  the  ACOC. 

The  presence,  in  Figure  6,  of  new  sector  suites  (bottom  left  of  Figure  6) 
and  old  position  equipment  (FVDs  and  flight  strip  printers  -  bottom  right 
of  Figure  6)  is  representative  of  the  fact  that  there  will  be  two  control 
rooms  at  each  ARTCC  from  the  time  sector  suite  installation  begins  until 
the  ISSS  becomes  sufficiently  stable  to  permit  removal  of  the  old 
equipment.  The  ISSS  configuration  must  permit  use  of  the  new  control 
room  for  ISSS  system  checkout  and  for  subsequent  training  of  controllers 
in  the  use  of  the  new  man/machine  interface  while  normal  ATC  operations 
with  the  Host  System  and  old  control  room  continue.  After  operational 
cutover  to  the  ISSS,  it  must  be  possible  to  switch  active  operation 
between  ISSS  (using  the  new  control  room)  and  the  Host  system  (using  the 
old  control  room).  The  VSCS  design  and  transition  plan  must  accommodate 
this  strategy  for  ISSS  checkout,  training  and  initial  operation. 

2.3.2  Backup  Mechanisms 

During  the  initial  ISSS  stabilization  period,  ISSS  failure  will  lead  to 
operation  with  DARC±/  (refer  to  Figure  6  for  this  discussion) .  Both 
radar  and  nan- radar  controllers  should,  in  most  cases,  be  able  to  get 
flight  data  information  from  the  normal  flight  data  backup  mechanism  that 
is  part  of  the  ISSS  design.  Attests  to  recover  full  ISSS  capability 
will  be  made  and,  if  successful,  ATC  operations  with  ISSS  will  resume. 

If  it  is  determined  that  ISSS  cannot  be  revived  fairly  guickly  (in  10-20 
minutes),  facility  personnel  will  switch  the  ISSS  out  of  the  active 
configuration  and  make  the  Host  System  (with  the  old  control  room)  the 
active  system.  At  that  time,  all  controllers  would  have  to  move  from  the 
new  to  the  old  control  room.  The  Host  System  will  require  a  relatively 
lengthy  startup  since  the  Host  software  for  this  operational 
configuration,  resident  in  a  separate  virtual  machine,  is  in  a  dormant 
state  and  receives  no  flight  and  radar  data  inputs  while  the  ISSS  is 
active.  As  in  the  case  of  transition  to  Host,  no  data  that  were 
generated  by  the  new  system  (ISSS  in  this  case)  will  be  used  for  the  Host 
system  startup.  Note  that  each  controller  has  the  option  of  using  DARC 
on  the  PVD  during  this  startup  period. 

The  second  level  fallback  mechanism  is  admittedly  awkward  since  it 
requires  an  en  masse  controller  move  from  one  control  room  to  another  and 
since  the  startup  after  the  move  is  slow,  (hi  the  other  hand,  this 


1/  Note  that  the  controller  will  have,  as  he/she  did  with  the  9020 
and  later  the  Host  System,  the  ability  to  switch  his/her  radar 
presentation  from  ISSS  to  DARC  at  his/her  discretion. 
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fallback  is  roquirad  for  only  a  abort  stabilisation  period  (oat lasted  at 
3  months  at  the  first  site  and  considerably  less  at  ether  sitae)  end 
problem  elimination  throng  extensive  ISSS  testing  is  ospected  to  Bake 
switchover  to  the  Host  systan  an  extronely  rare  event. 

2.3.3  Facility  Considerations 

To  carry  out  the  transition  to  ISSS  outlined  above,  a  new  control  roon, 
large  enough  to  house  the  sector  suites  needed  to  handle  all  of  an 
ARTCC's  sectors  (plus  spares),  oust  be  available.  Since  the  existing 
ARTGC  building  does  not  have  sufficient  space  for  a  new  control  roon,  an 
extension  nust  be  added  to  the  wing  that  houses  the  current  control  roon 
(see  Figure  5).  As  indicated  in  section  2.2.3,  this  wing  extension  will 
be  constructed  early  enough  to  house,  in  the  basement,  the  Host  computers. 

2. 3.3.1  Rationale  for  New  Control  Roon 


The  decision  to  add  to  the  wing  is  justified  on  several  grounds: 

(1)  ISSS  transition  is  significantly  simplified  with  this  approach. 
If  a  new  contol  roon  is  not  available,  an  incremental 
installation  of  sector  suites  nust  be  used  (i.e. ,  installing 
some  new  suites,  removing  sons  old  ones,  installing  note  new 
suites,  etc.).  This  would  lead  to  extensive  disruption  of  the 
control  roon,  an  operational  configuration  with  both  old  and  new 
suites,  and  a  such  longer  installation  period  (with  the 
accompanying  operational  disruption)  than  a  single  step 
replacement  of  sector  suites.  Furthermore,  the  approach  does 
not  provide  the  security  of  having  the  former  control  room  for 
fallback  purposes  during  some  of  the  installation  steps.  A  cost 
analysis  has  shown  the  cost  of  transition  with  a  wing  addition 
to  be  only  slightly  higher  than  the  cost  of  an  incremental 
transition. 

(2)  The  building  expansion  provides  sufficient  additional  space  to 
make  an  ARTCC  into  an  ACF.  In  addition  to  the  ACOC,  a  number  of 
other  new  co^xiter  systems  will  be  brought  into  the  ACF  as  part 
of  the  NAS  Plan.  The  basement  of  the  wing  extension  is  the  only 
place  where  one  could  realistically  have  a  large  enough  conputer 
roon  for  nany  of  these  systems.  Also,  as  terminal  sectors  are 
incorporated  into  the  ACCC,  the  number  of  sectors  in  many  ACFs 
will  be  larger  than  that  which  the  existing  control  roon  can 
house.  It  is  planned  to  use  the  space  vacated  by  removal  of  the 
PVDs,  flight  strip  printers,  etc.  for  the  terminal  control 
positions. 

2. 3. 3. 2  ISSS  Facility  Development  and  Installation 

To  carry  out  the  transition  to  ISSS  with  nininal  disruption  to  ATC 
operations,  a  carefully  staged  facility  plan,  that  includes  the  followiiy 
steps,  is  needed: 

(1)  Construct  the  wing  extension. 

(2)  Put  a  wall  between  areas  B  and  C  of  Figure  5.  The  control 
positions  are  currently  located  in  area  C.  This  is  the  area 
that  has  been  called  the  "old  control  roon". 
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(3)  Hove  the  equipment  in  are*  B  to  other  parts  of  the  facility. 
This  equipment,  in  eost  of  today's  facilities,  includes  the 
controller  training  lab  (DYSIM),  the  system  Maintenance  and 
ami  tor  console  (SMC),  teletypes  that  receive  flight,  weather 
and  other  data,  and  the  E-desk  coupler  (watch  supervisor,  flow 
control  position,  military  coordinator,  and  center  weather 
position) . 

(4)  Make  areas  A  and  B  into  a  single  rooa,  appropriately 
reconditioned  for  a  new  sector  suite  installation. 

(5)  Remove  the  old  radar  brite  display  equipment  (RBDE)  from  the 
basement  to  provide  additional  coaqjuter  room  space  for  ISSS  and 
VSCS  elements. 


(6)  Install  the  ISSS  equipment  including  any  new  computers,  the  LGN, 
and  sector  suites.  All  LCN  cabling  installation  necessary  for 
ACCC  operation  in  the  new  control  room  must  be  done  at  this  tine 
to  reduce  operational  disruption  during  ACCC  transition. 

Installation  of  ISSS  at  ARTCCs  will  begin  at  the  start  of  1989,  after 
extensive  controller  evaluation  of  the  new  man/nachine  interface,  full 
functional  tests  and  stress  tests  of  the  ISSS  at  the  FAATC.  ORD  of  the 
first  ARTCC  will  be  in  early  1990,  following  a  six  month  installation  and 
checkout  period,  and  nine  months  of  controller  training  and  tests.  ORD 
at  the  last  ARlcC  is  scheduled  for  early  1991.  The  AAS  prime  contractor 
will  be  responsible  for  installation  of  the  equipment.  FAA  will  accept 
the  ISSS  hardware  and  software  upon  contractor  demonstration  of  the  full 
system  in  an  operational  environment. 

2.3.4  Operational/Training  Impact 

The  introduction  of  ISSS  will  have  a  significant  iaq>act  cm  both  the 
controllers  and  the  hardware/software  maintenance  personnel.  The  ISSS, 
with  its  new  sector  suite  and  man/machine  "language,"  is  where  the  major 
AAS  changes  are  introduced  to  the  controllers.  Indeed,  the  goal  is  to 
limit  to  this  transition  step  the  changes  that  the  controller  will  see. 
When  the  ACCC  is  implemented,  the  controller  should  be  thoroughly 
familiar  with  ATC  operations  using  the  new  sector  suite  and  in  that  way, 
problems  with  the  ACCC  hardware  or  software  will  not  be  masked  by 
controllers'  unfamiliarity  with  the  nan/machine  interface.  While  new 
hardware  and  software  will  be  introduced  with  the  ISSS,  the  impact  will 
be  far  less  than  that  of  the  major  software  and  hardware  replacement  that 
accompanies  the  ACCC. 

Extensive  instructor  and  controller  training  in  the  use  of  the  new  sector 
suite  and  the  nan/machine  language  will  be  required  before  ATC  operations 
can  be  switched  from  the  Host  System  to  the  ISSS.  This  training  will 
include  initial  classroom  and/or  computer  based  instruction  followed  by 
extended  work  with  the  ISSS  equipment  in  simulation  node.  Nearly  one 
year  has  been  scheduled  for  controller  familiarization  and  training  at 
each  facility  prior  to  ORD. 


This  training  cannot  interfere  with  oegoiiv  ATC  operations  with  the  Host 
systen.  To  perait  training  of  the  entire  AKTGC  controller  population,  a 
significant  anount  of  overtine  will  be  required.  Since  the  l»st  Systen 
and  the  ISSS  share  a  significant  anoint  of  equipnent  (particularly  the 
Host  conputer),  care  oust  be  taken  in  ISSS  design  that  full  ISSS  trainiig 
and  ATC  operations  with  the  Host  systen  can  go  on  sinultaneously  without 
operational  inpact. 

Technical  training  will  be  required  for  the  ISSS  maintenance  workforce  in 
the  areas  of  sector  suite  consoles,  LCNs,  new  processors  introduced  with 
ISSS,  and  all  interin  hardware  (particularly  interfaces).  Software 
maintenance  training  will  be  required  for  all  new  software  and  software 
aodifications  that  are  part  of  the  ISSS.  This  includes  display  software, 
LCN  software,  electronic  flight  data  software,  interin/interface 
software,  adaptation  software,  and  support  software.  Since  software 
naintenance  will  be,  to  a  large  extent,  centralized  at  the  FAATC,  there 
will  not  be  a  requirement  for  extensive  software  training  at  ARTCCs.  The 
AAS  prime  contractor  will  be  responsible  for  developing  the  necessary 
hardware  and  software  training  programs  during  the  acquisition  phase  of 
the  AAS  procurement. 

2.3.5  Program  Considerations 

The  major  objectives  of  this  transition  step  were  to  introduce  a 
significant  element  of  the  AAS  early,  before  the  full  set  of  ACCC 
software  can  be  «aq>leted,  and  to  limit,  as  soon  as  possible,  the  need 
for  controller  staffing  increases. 

Breaking  the  transition  from  the  Host  system  to  the  ACCC  into  two  steps 
should  reduce  overall  program  risk  and  facilitate  what  has  been  judged  by 
many  to  be  the  most  difficult  aspect  of  the  Advanced  Automation  Program 
—  the  in  service  transition  to  a  totally  redesigned  system. 

These  objectives  must  be  accomplished  without  compromise  of  the  AAS 
system  design  and  without  the  need  for  extensive  interim  hardware  and 
software  as  part  of  the  ISSS.  As  many  of  the  new  ISSS  elements  as 
possible  should  become,  with  little  or  no  modification,  part  of  ACCC. 

The  policies  and  program  decisions  that  siq>port  this  are: 


(1)  The  sector  suite  console  (hardware)  developed  for  ISSS  will  meet 
all  ACCC  sector  suite  requirements. 

(2)  Bq>hasis  will  be  placed  on  the  design  of  the  total  Advanced 
Automation  System  itself.  Separate  development  of  ISSS  elements 
(except  for  the  sector  suite  console)  will  not  begin  until  after 
Critical  Design  Review  of  the  AAS. 

(3)  ISSS  scope  decisions  (i.e. ,  the  extent  to  which  Host  system 
elements  will  be  replaced  by  ISSS)  will  be  based  on  tradeoffs 
between  schedule  i^>act  and  interim  hardware/software  needs. 

(4)  ISSS  schedule  risk  will  be  reduced  by  limiting  the  sector  suite 
console  to  components  (particularly  the  display  head)  that 
require  little  or  no  technology  development. 


15 


(S)  The  scope  of  ISSS  mss  chosen  to  clearly  separate  the  lspact 

areas  of  ISSS  and  ACCC.  As  indicated  in  section  2.3.4,  the  ISSS 
has  a  aajor  iapact  on  the  way  the  controller  interacts  with  the 
ATC  autonation  systen  and  the  ACCC  has  a  najor  iapact  on  how  the 
new  hardware  and  new  software  carry  out  the  basic  ATC  functions. 

The  selection  of  ISSS  as  a  transition  step  to  the  ACCC  has  introduced  one 
risk  elenent.  The  standard  approach  of  designing  a  systen,  fully  testiig 
a  prototype,  and  then  starting  production  has  been  Modified  to  perwit  the 
early  introduction  of  the  ISSS.  In  particular,  the  production  decision 
for  sector  suite  consoles  will  be  based  on  liaited  tests  with 
deaonstration  software.  Full  tests  of  the  ISSS  at  FAATC  will  be 
conducted  in  parallel  with  the  sector  suite  console  production  startup 
(1987*1989,  see  Figure  6).  This  strategy  is  based  on  the  fine  belief 
that  the  Major  area  of  uncertainty  is  in  the  nan/nachine  language,  a 
software  function,  and  that  the  ref inenent  of  this  language  that  cones 
with  full  ISSS  test  will  not  require  sector  suite  console  redesign. 

Three  elenents  of  the  AAP  are  intended  to  linit  the  risk  of  this  approach 
and  to  ensure  that  the  ISSS  is  fully  suitable  for  operational  ATC  use 
when  installed.  These  are: 


(1)  Preparation  of  comprehensive  set  of  specifications  of  sector 
suite  console  and  nan/nachine  interface  (language)  requirements 
prior  to  award  of  AAS  contracts; 

(2)  Periodic  formal  review  and  participation  by  a  representative 
cross  section  of  controllers  and  other  Air  Traffic  Service 
representatives  throughout  the  Advanced  Autonation  Prog ran;  and 

(3)  Extensive  controller  tests  of  the  ISSS  systen  at  the  FAATC  and 
at  ARTCCs  prior  to  (XU). 

2.4  ACCC  Transition 

The  Area  Control  Computer  Complex  (ACCC)  transition  is  the  last  step 
(Step  2/3)  in  the  transition  from  the  9020  Systen  to  the  newly  design, 
modern  autonation  system  at  the  20  CONUS  ARTCCs.  The  Area  Control 
Computer  Complex  represents  one  of  the  najor  elenents  of  the  NAS  Plan. 
While  it  does  not,  when  initially  deployed,  represent  a  significant 
advance  in  ATC  operations,  it  does,  by  virtue  of  its  new  systen  design, 
provide  the  basis  for  future  ATC  systen  evolution. 

2.4.1  Systen  Definition 

2. 4. 1.1  System  Configuration 

The  ACCC  will  replace  the  remaining  elenents  of  today's  en  route  systen 
at  the  20  ARTCCs.  The  coagniter  hardware  and  software  elenents,  the  full 
LCN,  and  the  interfaces  to  other  ATC  system  elenents  that  make  up  the  AAS 
prime  contractor's  design  will  be  implemented.  The  ACCC  will  include  all 
emergency  mode  elenents  specified  in  the  AAS  specification  and  a  facility 


backup  mechanism  that  will  allow  adjacent  ACFs  to  take  over  the  airspace 
of  an  ACF  that  experiences  a  catastrophic  failure.!/ 

The  particular  ISSS  elements  that  will  bo  replaced  in  lids  step  include 
the  9020  software,  the  Peripheral  Adaptor  Modules  (INIs),  the  Display 
Channel  (if  not  replaced  in  the  previous  transition  step),  and  the  JMBC 
systea.  The  Host  computers,  which  will  be  readied  during  the  initial 
stabilisation,  will  be  replaced  according  to  the  contractor's  systea  life 
cycle  plan,  at  such  tine  as  it  is  econoaically  desirable. 

2. 4. 2. 2  Representative  ACCC  Architecture 

Figures  8  and  9  present  a  possible  1SSS/AGGC  transition  configuration 
(step  2/3)  and  one  of  nany  possible  final  ACCC  configurations.  The 
shaded  local  cnaaainl cations  network  is  representative  of  the  FAA 
requireaents  to  provide  future  growth  and  evolution  capability  and  to 
perait  replaceaent  of  individual  processors  (or  processing  subsysteas) 
through  use  of  one  or  aore  local  networks  based  on  standard  interface 
protocols.  Data  Inputs  froa  external  data  sources  could  coae  into  their 
network  directly  (as  shown  in  Figures  8  and  9)  or  could  coae  directly 
into  soae  of  the  ACCC  processors.  The  Host  and  processor  blocks  in  the 
upper  half  of  the  diagrams  are  representative  of  the  fact  that  the  ATC 
processing  will  be  dote  by  wore  than  one,  possibly  aany,  processors, 
quite  likely  supported  by  processing  subsysteas  (in  the  lower  half  of  the 
diagram)  associated  with  one  or  aore  individual  sector  suites.  The  AAS 
design  will  determine  the  rnaher  of  these  and  the  functional  allocations 
to  processors.  The  peripherals,  control  units,  and  connections  to 
processors  at  the  top  of  the  diagrams  are  indicative  of  the  likely  need 
for  peripheral  sigjport,  soae  shared,  by  several  of  the  ACCC  processors. 
The  change  froa  "Host"  in  Figure  8  to  "Processor"  in  Figure  9  is 
representative  of  the  requirement  for  a  systea  architecture  that  allows 
processor  upgrade/replaceaent  as  dictated  by  cost  or  capacity 
considerations  throughout  the  life  of  the  ACCC.  Figure  8,  based  on  the 
ISSS  architecture  postulated  in  Figure  7,  shows  that  the  initial 
transition  systea  permits  operation  in  an  ACCC  configuration,  in  an  ISSS 
configuration,  and  with  DARC.  Note  that  the  LCN  is  expected  to  eliminate 
the  need  for  physical  switches  to  switch  froa  one  of  these  configurations 
to  another. 

Figure  10  presents  another  conceptual  view  of  the  ACCC.  It  connotes  the 
generalized  distributed  ACCC  architecture  built  around  a  Local 
Communication  Network  (LCN).  Individual  ACCC  processors  or  processor 
subsysteas  are  tied  to  the  LCN  via  bus  interface  units,  and  external  data 
sources  are  connected  via  gateways.  The  "interfacility  data"  connection 
represents  the  requirement  for  communication  between  ACFs,  between  ACF 
and  ATCT,  and  with  other  (FAA,  military  or  foreign)  ATC  facilities.  The 
LCN  connections  to  MPS,  FSDPS,  and  CNF  on  the  left  side  of  Figure  10 
indicate  that  the  LCN  will  be  required  to  tie  these  to  the  ACCC  and  to 
one  another. 


17  Facility  backup  will  impose  new  interfacility  voice  and  data 
“  communications  requirements.  These  must  be  factored  into  the  FAA's 
overall  communication  system  planning. 
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During  the  initial  ACCC  stabilization  period,  ACCC  failure  will  lead  to 
operation  with  DARC  and  the  backup  flight  data  presentation  that  was 
introduced  with  ISSS.  Figure  8  is  indicative  of  the  requirement  that  the 
radar  display  of  the  sector  suite  oust  still  be  connected  to  DARC. 
Attempts  to  recover  the  full  ACCC  capability  will  be  made  and,  if 
successful,  ATC  operation  with  ACCC  will  resume.  If  it  is  determined 
that  ACCC  cannot  oe  revived  fairly  quickly  (in  10-20  minutes),  operations 
personnel  will  switch  the  new  ACCC  elements  (hardware  and  software)  out 
of  the  active  configuration  and  make  the  ISSS  the  active  configuration. 

In  Figure  8  this  includes  Host  with  9020  software,  the  interim  interfaces 
as  well  as  the  Display  Channel  (assumed,  as  it  was  in  section  2.3,  to  be 
part  of  ISSS  for  illustrative  purposes).  The  virtual  machine  operating 
system  in  the  Host  will  peimit  the  9020  software  required  for  fallback  to 
ISSS  to  start  up  from  dormancy  in  a  separate  virtual  machine  in  one  of 
the  Host  processors.  The  ISSS  and  ACCC  system  designs  will  determine  the 
precise  mechanism  ami  duration  of  ISSS  startup  after  switchover  from 
ACCC.  The  constraints  placed  on  the  AAS  contractor  in  developing  this 
mechanism  will  be  that  no  data  generated  by  new  ACCC  elements  be  used  for 
ISSS  startup.  As  in  the  case  of  transition  steps  0/1  and  1/2,  a  rapid 
startup  is  not  required  because  the  mechanism  will  only  be  used  for  a 
short  period,  and  then,  because  of  extensive  prior  testing,  only  rarely. 

2.4.3  Facility  Considerations 

Transition  to  the  ACCC  will  require  installation  activity  in  the  computer 
room,  in  the  ISSS  control  room,  and  in  the  old  control  room  vacated  by 
the  removal  of  PVDs,  etc.  New  ACCC  hardware  (processors  and  possible  new 
LCN  elements)  will  be  installed  in  the  computer  room.  This  will  require 
some  site  preparation  and  installation  of  new  hardware,  but,  because  of 
the  LCN  technology,  will  not  interrupt  ongoing  ISSS  system  operation. 

Control  room  installation  impact  will  be  minimal.  The  LCN  elements, 
installed  with  ISSS,  were  designed  for  full  ACCC  use  and  therefore  no 
cabling  work  is  needed.  Some  distributed  ATC  processor  system  upgrades 
may  be  required,  but,  the  LCN  design  is  required  to  permit  additions  of 
new  elements  to  the  network  without  operational  interruption.  If  this 
equipment  is  packaged  in  the  sector  suite,  instead  of  the  computer  room, 
the  upgrades  can  be  done  on  a  sector  suite  by  sector  suite  basis  and  will 
not  cause  any  more  interruption  than  routine  sector  suite  maintenance. 
After  the  old  control  has  been  refurbished,  LCN  and  new  sector  suites 
will  be  installed  in  the  "old*'  control  room  in  preparation  of  the 
operational  incorporation  of  terminal  sectors  into  ACCC.  This  will  be 
done  around  the  time  of  ACCC  transition,  but,  because  it  can  be  done  in  a 
sterile  environment  in  a  separate  control  room,  ongoing  ISSS  and  ACCC 
operations  will  suffer  little  disruption. 


Once  the  ACCC  has  become  operationally  stable,  the  last  elements  of  the 
current  NAS  system  and  any  interim  interfaces  can  be  removed.  Some 
interim  interfaces  will  have  to  be  removed  from  the  sector  suite 
consoles,  but  again,  this  can  be  done  as  part  of  the  routine  maintanance 
process  (extracting  cards  and  unplugging  cables)  and  should  not  degrade 
system  operation.  The  most  disnptive  removal  in  the  control  room  will 
involve  the  now  unnecessary  cables  between  DARC  and  the  sector  suites. 
All  other  elements  to  be  removed  are  outside  the  control  room,  either  in 


the  new  cc.puter  room  or  in  other  parts  of  the  ARTCC  building*  They  can 
be  electrically  isolated  froa  the  AGOC  and  therefore  removal  will  not 
affect  ATC  operations. 

Installation  of  ACCC  at  the  23  ACFs  will  begin  in  aid  1990,  after 
coaplete  functional  and  stress  tests  at  FAATC  (see  Figure  6).  ORD  of  the 
first  site  is  scheduled  for  1992  and  the  last  site  in  late  1993.  The  AAS 

?riae  contractor  will  be  responsible  for  installation  of  the  equipaent. 

AA  will  accept  ACCC  hardware  and  software  upon  contractor  deaonstration 
of  the  full  systea  in  an  en  route  operational  environment. 

2.4.4  Operational/Training  Impact 

The  iapact  of  ACCC  introduction  on  the  Air  Traffic  Controller  will,  as 
discussed  previously,  be  ainor  since  there  will  be  few  changes  to  the 
sector  suite  input /output  devices  or  to  the  nan/machine  interaction 
language.  Problems  with  the  new  software  and  hardware  will  be  readily 
identified  as  such  since  the  controller  is  by  now  thoroughly  faailiar 
with  the  use  of  the  new  sector  suite.  ACCC  will  contain  the  new 
functional  capabilities  of  AERA-1  but  these  will  not  be  made  available  to 
the  controller  until  after  ACCC  is  stable.  Controller  training 
requirements  for  this  transition,  therefore,  are  limited  to  the 
familiarization  with  the  initial  transition  fallback  mechanism,  ACCC 
failure  recovery  characteristics,  and  any  new  functional  capabilities. 

The  major  operational  impact  of  ACCC  transition  will  be  on  hardware  and 
software  operations  and  maintenance  personnel.  Training  in  ACCC  system 
operations,  new  hardware  maintenance,  and  software  maintenance  will  be 
required.  As  in  the  case  of  ISSS,  software  maintenance  will  be 
centralized  at  the  FAATC  and  therefore  there  will  not  be  a  requirement 
for  extensive  software  training  at  ARTCCs.  The  prime  contractor  will  be 
responsible  for  developing  the  necessary  hardware  and  software  training 
programs. 

2.4.5  Program  Considerations 

The  major  objective  in  this  transition  step  is  to  complete  the  ACCC 
installation  by  bringing  in  the  bulk  of  the  newly  designed  ATC  hardware 
and  software.  This  must  be  done  with  minimal  disruption  on  the  Air 
Traffic  Control  process,  both  during  installation  and  during  the  system 
stabilization  process.  Because  of  the  criticality  of  the  ATC  application 
and  because  of  the  difficulties  encountered  in  the  introduction  or 
transition  of  other  large  software  systems,  several  measures  will  be 
taken  to  achieve  this  objective: 

(1)  The  AAS  development  program  will  be  conducted  to  ensure  the 
maturity  of  the  software  at  the  time  of  ACCC  ORD.  A  top  down, 
structured  design  and  development  approach,  based  on  the  best 
software  engineering  principles,  will  be  adopted.  This  will  be 
supplemented  by  extensive  performance  modeling,  throughout  the 
design  and  development  process,  of  the  ISSS,  the  ACCC  and 
projected  future  ACCC  enhancements.  Extensive  functional  and 
stress  tests  will  be  carried  out.  first  at  the  FAATC  and  later 
at  the  field  sites  (see  Figure  6).  Finally,  to  assure 
compliance  with  requirements,  the  program  will  include  an 
extensive  Independent  Verification  and  Validation  (IV|V) 
activity. 
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(2)  The  transition  to  the  AGCC  will  be  transparent  to  the 
controllers.  This  is  accomplished  by  introducing  the  new 
man/machine  interface  at  an  earlier  transition  step  and  allowing 
sufficient  tine  between  the  steps  to  let  controllers  become 
thoroughly  familiar  with  this  new  interface. 

(3)  New  functional  capabilities,  such  as  AERA-l,  that  are  part  of 
the  ACCC  will  not  be  activated  until  operational  stability  of 
the  ACCC  is  achieved. 

(4)  Initial  operational  use  of  the  ACCC  will  be  limited  to  the  same 
airspace  and  sectorization  that  was  in  use  at  the  ARTCC  with  the 
ISSS.  The  transition  to  the  full  ACF  concept,  with  its 
realignment  of  en  route  airspace  and  consolidation  of  terminal 
sectors  into  the  ACCC  will  not  begin  until  the  ACCC  operation  is 
stable. 


2.5  Operational  Transition  to  ACFs 

The  last  three  sections  have  discussed  the  transition  from  the  9020  based 
en  route  system  at  the  20  CONUS  ARTCCs  to  an  Area  Control  Computer 
Complex  (ACCC)  at  an  Area  Control  Facility.  During  the  period  when  the 
ISSS  is  upgraded  to  an  ACCC  at  these  facilities,  the  three  ACFs  at 
Anchorage,  Honolulu,  and  at  the  New  York  TRACON  will  also  receive  an 
ACCC.  During  the  period  when  ISSS  serves  as  the  primary  ATC  automation 
system  at  the  ARTCCs,  the  additional  sector  suites  required  for  fully 
integrated  en  route/terminal  control  will  be  installed  at  the  20  ARTCCs. 
These  two  steps  complete  the  AAS  equipment  installation  at  an  ACF 
necessary  to  carry  out  the  operational  transition  to  the  ACF 
a i r space/cont  ro 1  concept . 

2.5.1  Completion  of  the  AAS  Installation  at  ACFs 

The  transition  to  the  ACCC  at  Anchorage,  Honolulu  and  the  New  York  TRACON 
will  be  accomplished  in  a  single  step  with  equipment  installed  in  a 
sterile  environment.  It  is  not  expected  that  the  ACCC,  when  installed, 
will  be  connected  to  any  elements  of  the  old  automation  system  at  the 
three  sites.  There  will  be  enough  sector  suites  installed  to  support  the 
final  ACF  configuration  at  each  of  these  three  sites. 

At  the  20  CONUS  ARTCCs,  enough  sector  suites  to  support  the  ARTCCs  (en 
route)  sectors  were  installed  as  part  of  the  ISSS.  Since  the  final 
number  of  sectors  at  some  of  these  20  ACFs  will  be  (significantly)  larger 
than  the  number  of  en  route  sectors  in  the  earlier  ARTCC  environment,  new 
sector  suites  must  be  added  to  the  ACCC  to  support  the  full  ACF  concept. 
The  old  control  room  (where  the  PVDs  were  located)  will,  as  described  in 
Section  2.4.3,  receive  the  additional  sector  suites  needed  for  ACF 
operation. 

To  avoid  disruption  of  ATC  operations,  it  is  currently  planned  to 
complete  the  entire  installation  at  a  facility  before  any  of  the  new 
sector  suites  are  activated  for  operations.  There  is  sufficient  time 
between  ISSS  0RD  (when  operation  switches  from  the  old  to  the  new  control 
room)  and  ACCC  0RD  (the  earliest  that  ACF  transition  could  begin)  to 
carry  out  this  installation.  Therefore,  unless  there  is  a  significant 
delay  in  removal  of  the  PVDs  and  flight  strip  printers,  this  requirement 
will  not  constrain  the  operational  transition  to  ACFs. 


roach  to 


*  After  the  above  steps  are  completed,  the  AOCC  trill  have  the  capacity  and 

functional  capability  to  support  a  fully  integrated  en  route/ terminal  ACT 
airspace  configuration  at  all  23  ACFs. 

’  The  operational  transition  from  a  system  with  20,  by  then  stable,  AGGCs 

performing  en  route  operations,  three  new  ACCCs  that  initially  have  no 
airspace  allocated  to  then,  and  the  many  ARTS  systems  and  offshore 
centers  to  a  system  where  the  ACCCs  at  23  ACFs  are  used  for  radar  control 
of  all  airspace  will  be  carried  out  gradually,  over  a  period  of  five  or 
more  years.  En  route  sectors  will  be  realigned  and,  where  necessary, 
airspace  operations  reassigned  to  a  different  facility.  Terminal  sectors 
can  be  gradually  brought  into  the  ACCC  -  probably  an  airport  at  a  time. 
When  the  radar  control  for  an  airport  is  incorporated  into  an  ACCC,  a 
TCCC  will  be  simultaneously  established  at  the  corresponding  Air  Traffic 
Control  Tower  (ATCT).  This  transition  will  present  both  operational  and 
communications  complexities  for  which  extensive  detailed  planning  will  be 
I  required. 

< 

|  As  in  the  case  of  the  three  steps  of  the  en  route  transition,  continuity 

of  service  is  of  the  utmost  importance.  To  provide  this  continuity,  it 
is  likely  that  for  some  initial  period  both  the  old  terminal  (ARTS)  radar 
positions  and  the  new  positions  in  the  ACCC  control  room  will  be  manned 
to  provide  a  fallback  to  the  old  system  should  the  new  system  fail.  In 
many  cases,  the  old  terminal  radar  positions  being  replaced  will  not  be 
located  in  the  ACT  where  the  new  positions  will  be.  This  means  that 
control  teams  would  be  needed  at  both  the  ACT  and  at  the  old  teiminal 
facility.  Therefore,  if  such  a  fallback  scheme  is  selected  to  support 
continuity  of  operation,  extensive  controller  overtime  is  expected.  This 
approach  would  also  require  old  and  new  tower  control  position  equipment 
to  coexist  for  a  limited  period  in  a  tower  cab.  Because  tower  cab  space 
is  at  a  premium,  this  requires  careful  planning  and,  in  some  instances 
temporary  towers  may  have  to  be  used. 

* 

The  operational  impact  of  the  transition  to  the  full  ACF  concept  will  be 
?  felt  by  the  en  route  controllers  at  the  ACCC  as  well  as  the  terminal 

controllers.  As  en  route  sectors  are  realigned  and  facility  boundaries 
changed,  the  en  route  controllers  will  have  to  become  familiar  with  the 
new  sector  geographies,  new  sector  to  sector  interfaces,  and  new  facility 
to  facility  interfaces.  The  operational  impact  of  the  consolidation  of 
terminal  sectors  into  the  ACCC  is  significant.  Just  as  the  en  route 
controllers  had  to  begin  using  a  totally  new  man/machine  interface  with 
ISSS  introduction,  the  approach  and  departure  controllers  will  now  have 
to  use  the  sector  suite  instead  of  the  currently  existing  ARTS  systems. 
The  transition  may  be  even  more  difficult  since  many  of  the  controllers 
may,  for  the  first  time,  be  using  an  all  digital  radar  situation  display 
and  since  many  of  them  will  be  moving  to  an  ACT  from  an  environment  where 
they  routinely  work  shifts  in  both  a  TRACON  and  a  tower  cab.  The  tower 
cab  controllers  will  also  be  affected  since  they  will  begin  to  use  the 
new  TCCC  position  equipment  at  this  time. 

i 
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Operation  and  Maintenance  Upset  will  be  felt  primarily  in  tile  tower  cab 
since  the  equipment  installed  at  ACFs  will  be  identical  to  equipment 
already  present  in  the  facility.  In  the  TOCC  there  will  be  new  displays, 
computers,  sensor  interfaces,  and  software  that  wust  be  Maintained.  As 
with  all  other  AAS  components,  software  Maintenance  will  be  centralized 
at  FAATC. 

A  training  prog  ran,  developed  by  the  AAS  priwe  contractors,  will  be 
required  for  the  terminal  controllers  who  will  be  using  the  AGOC.  this 
training  will  have  to  be  carefully  planned  and  integrated  into  the 
operational  transition  plans  since  the  controller  training  wust  be 
conducted  at  the  FAA  Acadeny  or  an  ACF,  with  the  new  equipnent,  rather 
than  at  individual  TRACONs.  Controllers  fron  TRACONs  Must  Move  to  the 
FAA  Acadeny  or  ACFs  for  this  training  and  therefore  cannot  receive 
training  during  overtime  hours.  Overtine  at  the  terminals  will  be 
required  to  support  the  absence  of  controllers  attending  these  training 
courses. 
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3.0  SUMMARY 


Transition  to  a  totally  now  ATC  automation  syatan  is  perhaps  the  most 
difficult  aspect  of  the  Advanced  Autonation  Program.  Many  programs, 
often  involving  systems  smaller  and  less  complex  than  die  ATC  automation 
system,  have  failed  because  transition  was  inproperly  planned  and  the 
transition  steps  were  overly  ambitious.  Experience  tells  us  that 
breaking  the  transition  into  a  number  of  manageable  steps  greatly 
inproves  the  probability  of  program  success. 

The  AAS  transition,  besides  dealing  with  a  very  large  embedded  system,  is 
complicated  by  the  fact  that  it  is  an  in  service  transition  that  cannot 
tolerate  lapses  in  stability  and  availability  of  service.  The  system  to 
be  replaced  constrains  possible  approaches  to  transition  by  virtue  of 
inflexible  and  non-standard  hardware  interfaces  and  by  virtue  of  software 
that  does  not  lend  itself  to  partitioning  and  therefore  step-wise 
replacement. 

The  AAS  transition  approach  must  also  meet  a  number  of  broader 
requirements.  First,  capacity  relief  must  be  provided  in  the  1986/87 
timeframe  at  some  en  route  centers.  Second,  to  limit  controller  staffing 
increases,  a  high  priority  has  beat  placed  on  early  controller 
productivity  gains.  Finally  the  AAS,  as  an  integrated  part  of  the  NAS 
Plan,  must  support  the  ambitious  transition  from  today's  terminal/en 
route  environment  to  a  consolidated  system  with  23  Area  Control 
Facilities. 

The  transition  approach  that  has  been  presented  here,  consisting  of  a 
three-step  transition  to  an  Area  Control  Computer  Complex  at  the  20 
ARTCCs  followed  by  an  operational  transition  to  ACFs  at  23  sites,  is  the 
result  of  extensive  analysis  and  planning.  It  meets  the  NAS  Plan 
objectives  with  minimal  operational  disnption  and  with  manageable, 
technical,  cost  and  schedule  risk.  It  can  be  achieved  without  the  need 
for  extensive  interim  hardware  and  software  and  without  compromise  of  a 
new  system  design  for  the  1990's  and  beyond.  Proper  attention  to  this 
design  will  allow  FAA  to  take  advantage  of  the  potential  of  computer 
technology  of  the  1980's  and  thereby  achieve  a  system  architecture  that 
will  lead  to  a  long  system  life  and  future  system  growth  in  an 
evolutionary  manner. 

In  closing,  it  must  be  kept  in  mind  at  all  times  that  this  paper  has  only 
presented  an  approach  to  guide  the  transition.  The  ultimate  success  of 
the  Advanced  Automatical  Program  will  depend  on  extensive  and  careful 
planning  for  the  implementation  of  this  approach. 
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FIGURE  1.  EN  ROUTE  SYSTEM  TRANSITION  STATES 


3:  TRANSITION  TO  HOST,  STATE  0/1 


HOST  AFTER  REMOVING  9020,  STATE  1 
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FIGURE  6.  TRANSITION  TO  ISSS,  STATE  1/2 
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TRANSITION  TO  ACCC,  STATE  2/3 


CONTROL  UNITS 


FIGURE  9.  AREA  CONTROL  COMPUTER  COMPLEX,  STATE  3 


FIGURE  10.  AREA  CONTROL  COMPUTER  COMPLEX  -  ANOTHER  VIEW 


